Tracking several open data connections is difficult with a large number of connections. For example, Fibre Channel uses a large number of frame sequences. Tracking these open data connections or frame sequences in the case of Fibre Channel requires monitoring the status of the data connections. For example, a data connection is disrupted when a frame is lost or dropped because of a data error, or when a remote link partner is disconnected due to an error. Checking a connection for a “timeout” indicates such a connection disruption. A “timeout” is indicated by a connection not transmitting or receiving any packets in an excessive period of time.
For example, consider a connection with a timeout value of 2 seconds that receives a packet at time t=0 s, and then sends a reply at t=1 s. The connection “times out” if it does not receive or transmit another packet before t=3 s.
Some implementations of timeout monitoring use a microprocessor and software to check each of the several connections for a timeout. In this implementation, software instructs the processor to loop through the connections and access each open connection's data structure to check for a timeout. The processor loops through the connections indefinitely because a connection can timeout at any time. In this implementation, the processor is either embedded in the connection tracking hardware, or an external processor is available to indefinitely check for timeouts. Connecting an additional processor just for timeout monitoring is undesirable in some systems, like a high-throughput streaming system, because large logic electronics used to connect the additional processor generally run slower than the connection data rate. Such an implementation is unnecessarily complex and costly.